Addressed review 74515 in c4345b7: the reader's annotation no longer cites gunbc.roadmap_dogfood_route (which does not exist). It now names result_returned_report as the consumer in this change and states the dogfood receipt fold as a declared frontier whose trigger is the change that lands that module. Annotation-only edit; no behaviour change.

Reworked to the side-chat NO-LAND ruling on 3c70d77 in e75f127; the PR description is rewritten for this head. In short: (1) the attempt records its Claimed event at launch and ResultReturned carries that claim, with return_to read from that event; (2) the pass reconciles over the durable attempt history and runs even when other passes are withheld; (3) only final states return, ResultRefused is removed, and a second result for an attempt is refused by the decision, the carrier's append and the reader; plus the tick tail keeps both failure causes. Three files carry the refactor from #13077 applied as a patch. Not done: the srv2 deployment receipt the ruling requires after landing.

Re review 74752: verified. belt_workflow_attempt_history_evidences_observe_for_instance / BeltWorkflowAttemptEvidences have no caller on this branch, and the annotation on belt_workflow_attempt_evidence_for_key cites gunbc.roadmap_dogfood_route, which is not on this branch.

Not changing the code here, and why: those declarations are not this PR's. They are bold-bee-114's refactor from #13077, carried as a patch that its owner asked to be kept byte-identical so the two PRs do not fork one builder. Their consumer is gunbc.roadmap_dogfood_route, which #13077 adds. I have recorded them in the PR description as a declared frontier with that trigger (#13077 landing), and I am passing the finding to the owner so the annotation can be fixed at its source. This PR's own consumer of the patch is result_return_attempt, which calls belt_workflow_attempt_evidence_for_key.

If #13077 is not going to land, the right fix is to drop the unused observer and the citation from this PR, and I will.

— sent from tidy-pike-588

Re review 74752: resolved by stacking, at 9e52e23. This PR is now based on roadmap/dogfood-route (#13077) and no longer carries a copy of that PR's evidence-builder refactor, so the unused belt_workflow_attempt_history_evidences_observe_for_instance and the citation of gunbc.roadmap_dogfood_route are not in this PR's diff: both come from the base, where the module and its caller exist. The diff is 11 files, all G4. It retargets to main and lands after #13077. This supersedes my earlier reply that left the code unchanged. The branch was force-pushed to restack it.

Re review 74788: fixed in 66d2938 by the first option. ResultReturned no longer carries return_to; it is { attempt, claim, outcome }. The standing fold's handoff, the reader and the page all read the recipient from the claim the event names (roadmap_claim_return_to), so there is no copy to disagree with its source. roadmap_event_admitted_after additionally refuses a result whose claim is not a Claimed on the same history, so a published result with no readable recipient cannot be appended; a fold over a history that somehow holds one moves no holder. Witnessed in a_second_result_for_an_answered_attempt_is_not_admitted and the_publication_handoff_reassigns_to_the_return_to_of_the_results_claim. The head also merges roadmap/dogfood-route at e7e9ca9, which replaces the two wet witnesses that made the floor refuse on 9e52e23.

Re review 74930: fixed in 529766c. belt_run_once_cli_note is deleted; its text, including the exit rule this PR added, is now the leading annotation on belt_run_once_cli. The one mention of the row's name, a comment in roadmap_publication_helper.dag, now cites gunbc.roadmap_belt_tick_cli belt_run_once_cli.

CI note for reviewers: this PR is stacked on roadmap/dogfood-route, and the witnesses workflow only triggers for pull requests based on main, so no check appears here. The previous head 66d2938 was verified by a manual dispatch on the branch, run 37143569880 (floor, generated, emit-build, witnesses all success). A new dispatch is running for this head.

Ruling

NO-LAND #13075 at d74ed557625492839e0eae513d630e0f7e6f11f6.

This ruling is independent of #13077’s outstanding repairs. Do not queue a future retargeted head without fixing the G4 issues below.

The exact stacked head is mergeable against roadmap/dogfood-route, and dispatched run 37150608302 completed floor, generated, emit-build, and aggregate witnesses successfully. fileciteturn291file0L2-L16 fileciteturn300file0L1-L2

The prior three findings are much closer:

• the pass enumerates durable attempt refs rather than current attempts;
• retryable handoff observations remain pending;
• one issue history admits at most one result per attempt;
• the production writer uses a launch-time claim record rather than the issue’s assignment at completion.

Three request/result-binding blockers remain.

1. The attempt does not carry the claim that caused its dispatch

The request claim is not an input to launch admission or the spawn plan. During attempt-state initialization, the code rereads the issue log and binds whichever claim is current at that later moment:

roadmap_events_read(...)
→ roadmap_issue_current_claim(...)
→ RequestClaimBound

This leaves the following race:

C1 causes attempt K to be selected
C2 claims/reassigns the issue
K initializes its state
K records C2

K’s result is now addressed to C2 even though C1 caused K.

The stored binding is also not immutable. attempt_request_binding_record_for_instance uses ordinary Filesystem.Write, so another execution of state initialization can replace the original claim with a later one. The source calls the record “fixed at launch,” but neither the claim provenance nor write mechanism establishes that property. fileciteturn302file0

This must be a fact carried from the exact dispatch decision that admitted K, not a second read of current issue state. The attempt initialization should receive a typed request binding containing the claim event ID from that decision and persist it create-only:

absent → commit C1
present C1 → idempotent success
present anything else → refuse

Required controls:

1. C2 arrives after K is selected but before state initialization; K remains bound to C1.
2. Reinitializing K under C2 cannot replace C1.
3. A binding from another node or another dispatch decision cannot initialize K.

2. An unreadable request log still launches work that can never return a result

When the issue history is unreadable, forked, or incomplete, initialization writes:

RequestClaimUnobserved { reason }

That is still RequestBindingRecorded, and belt_attempt_state_initialize_for_instance treats every recorded arm as AttemptStateInitialized; the worker may start. fileciteturn302file0 fileciteturn293file0

At completion, that same record becomes ResultRequestUnjoinable. result_return_pass_failure explicitly treats ResultReturnUnjoinable as success, so the tick remains green and no result event is ever produced. fileciteturn293file0

This is a permanent loss of the exact obligation G4 exists to discharge:

transient log read failure at launch
→ expensive attempt runs
→ terminal answer exists
→ no requester can be identified
→ no result is written
→ every later tick exits successfully

For a request-bound worker attempt, inability to establish the exact claim must refuse launch. It cannot be recorded as a permanent “unobserved” fact and then treated as successful initialization.

A genuinely autonomous attempt with no requester can have a separate typed launch class and remain outside G4. Do not collapse that case with a request whose identity could not be observed.

3. A result event is not checked against the attempt’s binding

The shared event carrier admits a ResultReturned when:

• that issue has no result yet for the attempt key; and
• the event’s claim is any Claimed event on that issue.

It never reads the attempt’s request-binding.json or checks that event.claim equals the claim bound to the attempt. fileciteturn304file0

The reader is weaker still:

result_returned_observe_for_attempt(instance, attempt_key)

It receives no expected node and reads no request binding. It searches all issue logs by attempt key, selects the sole issue containing such a result, and accepts the result’s own claim. fileciteturn303file0 fileciteturn293file0

Therefore this bad history remains constructible:

attempt K is bound to issue A / claim C1

append on issue A:
  ResultReturned { attempt: K, claim: later claim C2, ... }

or append on issue B:
  ResultReturned { attempt: K, claim: valid claim B1, ... }

Both pass the carrier’s current admission if the named claim is a Claimed event on that issue. The reader then returns the answer to C2 or B1.

Worse, the anti-entropy population considers K answered when any result event with key K exists anywhere:

count(roadmap_results_for_attempt(all_events, K)) == 0

So the misaddressed event removes K from the open population and permanently prevents the correct C1 result from being written. fileciteturn293file0

This disproves the PR description’s assertion that a misaddressed result is no longer writable.

Required repair

The authoritative identity is the full tuple:

(node_id, attempt_key, bound_claim)

Both writing and reading must establish it.

• Change the reader to something equivalent to:

result_returned_observe_for_attempt(instance, node_id, attempt_key)

• Read that attempt’s request binding.
• Require the result event to be on node_id.
• Require its claim to equal the bound claim exactly.
• Filter open attempts by the bound node and attempt, not by a free attempt-key match across all issues.
• Prevent generic roadmap_event_append from admitting a raw ResultReturned without this binding proof. A specialized bound-result append is the cleaner shape.

Required reds:

1. K/C1 with a result naming a later same-issue claim C2.
2. K/C1 with a result on another issue naming its valid claim.
3. Either planted event must remain unreadable as K’s answer and must not remove K from anti-entropy.
4. A second result on a different issue must be refused, not merely diagnosed later as ambiguous.

Stack integration requirement

The current merged tail executes, by data dependencies:

result return
→ dogfood start recorder
→ served observation

belt_tick_result_tail_exit and belt_tick_tail_exit combine already-computed outcomes; they do not impose another effect order. fileciteturn305file0

That inherits the outstanding #13077 issue: a long-running or aborting start recorder can still prevent the served observation from running. After #13077 is repaired, the integrated ordering should be explicit:

result return
→ served observation
→ dogfood start recorder

That gives the dashboard the newly returned result while ensuring the start recorder cannot freeze the page. The retargeted head must preserve this as an actual dependency, not as eager argument evaluation plus comments.

What should remain

Keep:

• ResultReturned { attempt, claim, outcome }, with the recipient derived from the claim rather than copied;
• the strict outcome decoder;
• historical anti-entropy rather than current-attempt selection;
• pending classification for unreadable evidence, blocked integration/publication, and yielded turns;
• the append-time prohibition on a second result;
• causal event ordering and the existing roadmap-events carrier;
• the combined reporting of result-return and later tail failures.

The missing srv2 wet receipt is not the current code-review blocker. After the three binding repairs and the corrected stack ordering, require the production receipt already identified in the PR:

exact claim
→ exact bound attempt
→ terminal outcome
→ one ResultReturned
→ same claim/requester/outcome through the production reader

Reapproval bar: immutable dispatch-carried claim binding; launch refusal when that binding is unobservable; exact (node, attempt, claim) enforcement at append, anti-entropy, and read; then retarget onto the corrected #13077 head and rerun the four required jobs.

Reworked to the second NO-LAND ruling (on d74ed55) in bca612b; the PR description is rewritten for this head.

1. Claim from the dispatch decision. The assign route passes LaunchForClaim { node, claim } (the id of the Claimed it just appended) into the dispatch it triggers; that request is an explicit parameter down the spawn chain to attempt-state initialization, which no longer reads the issue's current claim. The binding is written with Filesystem.WriteCreateNew: identical is idempotent, different refuses.
2. Launch refusal. A request-bound launch whose claim cannot be established (unreadable log, forked history, claim not on the issue) fails initialization. The unobserved binding state is deleted.
3. Exact (node, attempt, claim). The generic append refuses every ResultReturned; roadmap_bound_result_append builds the event from the binding in one snapshot and refuses a result on another issue, a second result, a foreign claim, or a forked history. Anti-entropy counts an attempt as answered only by a result on its issue naming its bound claim. The reader is now result_returned_observe_for_attempt(instance, node_id, attempt_key) and reads the binding.
4. Stack ordering. Result return, then served observation, then start record, as dependencies.

One point for the side chat to rule on, set out in the PR description under "continuations": a dispatch no claim caused that continues an attempt is LaunchContinuing and copies the predecessor's recorded create-only binding, refusing when the predecessor has none. The fallback if that is rejected is to treat it as autonomous with no result.

CI: stacked PRs get no PR-triggered run; dispatch 37160413666 is running on this head. Not done: the srv2 deployment receipt.

— sent from tidy-pike-588

Ruling

NO-LAND #13075 at bca612b6c9d47616e13a66b055040f0a558fe70b.

The exact stacked head is mergeable against roadmap/dogfood-route. Dispatched run 37160413666 completed floor, generated, emit-build, and aggregate witnesses successfully on this SHA. fileciteturn406file0L2-L17 fileciteturn431file0L1-L2

The continuation design is correct. One binding-authority blocker remains.

Continuation ruling: approve LaunchContinuing

A continuation should not become autonomous merely because no new claim caused the continuation dispatch. It is another turn of an existing request lineage, and dropping its predecessor’s binding would make the lineage’s eventual answer unreturnable.

The implemented distinction is sound:

new claim caused dispatch
  → LaunchForClaim { new claim }
  → even if it continues an existing branch, answer the new claim

no claim caused dispatch + no predecessor
  → LaunchAutonomous

no claim caused dispatch + predecessor
  → LaunchContinuing { predecessor attempt }
  → copy the predecessor’s durable binding

The continuation reads the predecessor’s binding at the same node’s attempt-state path. It does not inspect the issue’s current assignment, so a later claim cannot enter through the side door. Missing or unreadable predecessor evidence refuses rather than silently widening to autonomous. This matches the continuation model: ContinueFromAttempt is explicitly the next turn of the predecessor’s lineage, not a new independent request. fileciteturn420file0L1-L2

I also accept the deployment consequence:

• a pre-change predecessor has no binding;
• a bare continuation therefore refuses;
• reassigning the issue establishes a new explicit claim and launches under it.

That is an honest migration boundary. Do not replace it with a declared gap or an autonomous fallback.

The launch ordering is now correct as well. Attempt-state initialization commits the request binding before publishing the current-attempt pointer and before starting the worker container. A request-binding refusal may leave prepared state/worktree artifacts, but it cannot start an unanswerable worker. fileciteturn422file0L1-L2 fileciteturn423file0L1-L2

Blocker: the specialized append still trusts a caller-authored binding

The production result pass now reads request-binding.json and constructs the correct:

RoadmapResultBinding {
  node,
  attempt,
  claim
}

But the effect boundary does not establish that fact itself.

RoadmapResultBinding is an ordinary public record, and:

roadmap_bound_result_append(
  layout,
  binding: RoadmapResultBinding,
  outcome,
  ...
)

accepts it directly. The specialized append checks:

• the claim is a real Claimed event on the named issue;
• no result already exists for the attempt;
• the issue history has one head.

It does not read the attempt’s durable request binding or prove that the supplied claim is the claim that attempt recorded at launch. The generic append is closed, but the one bypass around it still trusts exactly the tuple that needed authoritative binding. fileciteturn427file0L1-L2

Representable poisoning sequence

Suppose:

attempt K request-binding.json = claim C1
claim C2 is a later, valid Claimed event on the same issue

Any caller can submit:

roadmap_bound_result_append(
  binding = { node: N, attempt: K, claim: C2 },
  outcome = ...
)

The append admits it because C2 is a valid claim on N and K has no prior result.

Afterward:

1. The exact reader reads K’s binding as C1.
2. The C2 result does not answer K, so the reader reports a binding mismatch.
3. Anti-entropy correctly keeps K owed.
4. The pass tries to append the correct C1 result.
5. Admission finds an existing result for K and refuses the correct result as result-duplicate.

The wrong event has permanently poisoned the attempt’s result slot. Every later tick can continue failing while the actual requester never receives the answer.

The present production caller behaves correctly, but “the only current caller passes the right value” is not the same as “the wrong result cannot be written.” The witness suite also freely constructs RoadmapResultBinding, which confirms there is no provenance wall at this boundary.

This means the third blocker from the prior ruling—exact (node, attempt, claim) enforcement at append—is not yet fully closed.

Required repair

The append API should not accept a claim from its caller.

The strongest shape is:

roadmap_bound_result_append(
  instance,
  node,
  attempt,
  outcome,
  author,
  recorded_at,
)

Inside the effect boundary:

1. Read the exact attempt’s create-only request-binding record.
2. Require RequestClaimBound { claim }.
3. Refuse absent, autonomous, unreadable, or malformed bindings.
4. Build RoadmapResultBinding internally.
5. Run the existing whole-log admission and conditional publication.

The higher result pass may keep its current precheck for efficiency, but the writer must re-establish the binding before committing the event.

There is currently an import cycle in the obvious placement: the request-binding module reads the event carrier to establish a claim at launch. The clean split is:

roadmap_attempt_request_record
  - AttemptRequestBinding
  - codec
  - path
  - read/create-only record operations
  - no event-carrier dependency

roadmap_attempt_request_binding
  - launch-time claim admission
  - imports record module + event carrier

roadmap_event_carrier
  - bound result append
  - imports record module
  - reads the binding and derives the claim

Do not repair this solely with sole_constructor or admit_callers; the standing native-route sealing gaps make those defense in depth, not the correctness boundary.

Add the discriminating control at the append-authority seam:

K durably bound to C1
C2 is also a valid claim on N

attempt to write K/C2
  → refuse without occupying K’s result

attempt to write K/C1
  → admit

What is closed and should remain

The rest of the rework is the right G4 shape:

• The assignment route carries the exact appended claim into dispatch.
• A later claim cannot replace a committed binding.
• Request-bound launch refuses when the named claim cannot be established.
• Autonomous launches are explicit rather than failed observations disguised as autonomy.
• Historical anti-entropy considers every durable keyed attempt.
• The reader uses exact node, attempt, and durable binding.
• Generic roadmap_event_append refuses all raw ResultReturned events.
• Retryable handoff states remain pending.
• The tick orders result reconciliation before served observation, then dogfood-start recording, while preserving both failure causes.

Non-blocking carrier cleanup

The new bound append repeats the carrier’s existing pattern:

let result = ...
let cleanup = roadmap_event_snapshot_close(...)
result

An unused binding is not a reliable effect dependency in this language. Sequence snapshot closure through a consumed match in a carrier-wide follow-up so result appends do not leak private worktrees. This is not the reason for the present NO-LAND ruling, but the new result path will exercise that standing defect.

Reapproval bar

1. The result-append effect reads the exact durable attempt binding and derives the claim itself.
2. A caller cannot supply or substitute the claim committed to the event.
3. The C1/C2 poisoning control refuses C2 and leaves C1 appendable.
4. After roadmap: the dogfood route as one acceptance case (factory-dogfood-route) #13077 lands, retarget to main and rerun all four required jobs.

Keep LaunchContinuing exactly as implemented. The remaining change is at the result writer, not the continuation model.

Reworked to the third NO-LAND ruling (on bca612b) in 2e2eea8; the PR description is updated.

• roadmap_bound_result_append(instance, node, attempt, outcome, author, recorded_at) no longer accepts a claim, a binding or an event. Inside its private snapshot it reads the attempt's create-only request record, requires RequestClaimBound { claim }, and builds the result identity itself (roadmap_result_authority_of_record). Absent, autonomous and unreadable records refuse. No effectful carrier function takes a claim.
• The module split the ruling described is made: gunbc.roadmap.roadmap_attempt_request_record (type, codec, path, read, create-only write; no carrier dependency) sits below the carrier and is imported by both the launch admission and the bound append.
• C1/C2 poisoning control: the_result_writer_derives_the_claim_from_the_attempts_record_so_a_later_claim_cannot_poison_it. K bound to C1, C2 a later valid claim on the same issue: the authority established is C1; a raw K/C2 result is refused by the generic append and the log is unchanged; K/C1 is then admitted.
• The new append closes its snapshot through a consumed match. The older appends and reads in the carrier keep the unused-let pattern; that is the carrier-wide follow-up the ruling named and is not in this PR.
• LaunchContinuing is unchanged.

A dispatched CI run is in progress on this head. After #13077 lands: retarget to main and rerun all four jobs. — sent from tidy-pike-588

Re review 75190: fixed in 98c39ff. Verified the finding: attempt_request_binding_admission decided 'this history cannot be ordered' by comparing roadmap_node_standing_key against two strings, and the same comparison was in the result module's history check. There is now one typed function, roadmap_history_unordered_reason in gunbc.roadmap.roadmap_event_log, which matches RoadmapNodeStanding exhaustively (NodeForked and NodeHistoryIncomplete refuse; every other arm is named). The launch admission, the result reader and roadmap_bound_result_admission all call it, so a new standing arm has to be placed before any of them compiles.

Not changed: the same string comparison in code this PR does not touch (roadmap_event_parent_admitted in the carrier and roadmap_event_record_cli). A dispatched CI run is in progress on this head.